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1. INTRODUCTION 
1.1 General characteristics of signalling connection control procedures. 


1.1.1 Purpose. This Recommendation describes the procedures performed by the Signalling 
Connection Control Part (SCOP) of Signalling System No. 7 to provide both connection-oriented and 
connectionless network services as defined in Recommendation Q.711. These procedures make use of 
the messages and information elements defined in Recommendation Q.712, whose formatting and coding 
aspects are specified in Recommendation Q.713. 


1.1.2 Protocol classes. The protocol used by the SCCP to provide network services is subdivided 
into five protocol classes, defined as follows: 


— Class 0 : Basic connectionless class, 

— Class 1 : Sequenced (MTP) connectionless class, 

— Class 2 : Basic connection-oriented class, 

— Class 3 : Flow control connection-oriented class, and 

— Class 4: Error recovery and flow control connection-oriented class. 


The connectionless protocol classes provide those capabilities that are necessary to transfer one 
Network Service Data Unit (NSDU), {i.e., one user-to-user information block) in the user data field of a 
Unitdata message. The maximum length of an NSDU is restricted to 255 octets! since segmenting and 
reassembly are not provided by protocol classes 0 and 1. 


The connection-oriented protocol classes (protocol classes 2, 3, and 4) provide segmenting and 
reassembly capabilities. If a Network Service Data Unit is longer than 255 octets, it is split into 
multiple segments at the originating node, prior to transfer in the user data field of Data messages. 
Each segment is less than or equal to 255 octets! At the destination node the NSDU is reassembled. 


1.1.2.1 Protocol class 0. Network Service Data Units passed by higher layers to the SCCP in the 
node of origin are delivered by the SCCP to higher layers in the destination node. They are transported 
independently of each other, therefore, they may be delivered out-of-sequence. Thus, this protocol class 
corresponds to a pure connectionless network service. 


1.1.2.2 Protocol class 1. In protocol class 1, the features of class 0 are complemented by an 
additional feature (i.e., sequence control parameter associated with the N-UNITDATA request primitive) 
that allows the higher layer to indicate to the SCCP that a given stream of NSDUs have to be delivered 
in-sequence. The Signalling Link Selection (SLS) field is chosen, based on the value of the sequence 
control parameter. The SLS chosen for a stream of NSDUs with the same sequence control parameter 
will be identical. The SCOP will then encode the Signalling Link Selection (SLS) field in the routing 
label of messages relating to such NSDUs, so that their sequence is, under normal conditions, 
maintained by the signalling network as defined in Recommendation Q.704. Thus this class corresponds 
to an enhanced connectionless service where an additional sequencing feature is included. 


An asterisk '*’ indicates a change from the CCITT Red Book Vol. VI which is specific to U. S. Networks. 


A bar ’|’ indicates a change from Issue 1 of Bell Communications Research Specification of Signalling System Number 7, 
Vol. 1 and 2. 


1. The transfer of up to 255 octets of user data is allowed provided that the maximum length of signal units chosen for the 
network as specified in Q.703 is not exceeded. 
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1.2 Outline of removed text. 


The current implementation of the SCCP provides for connectionless service only, using protocol 
classes 0 and 1. Thus, the text pertaining to connection-oriented procedures and protocol classes 2, 3, 
and 4 has been removed. In order to put the text provided at this time into perspective, an outline is 
given below that lists sections temporarily removed. 


1.1.2.3 Protocol class 2 

1.1.2.4 Protocol class 3 

1.1.2.5 Protocol class 4 

1.1.7 Protocol class 4 

1.1.3 ..Signalling connections 

ey Overview of procedures for connection-oriented services 
1.2.1 Connection establishment 

12.2 Data transfer 

L253 Connection release 


1.3 Overview of procedures for connectionless services. 


1.3.1 General. When the SCCP functions at the node of origin receive from a higher layer an NSDU 
to be transferred by the protocol class 0 or 1 connectionless service, the Called Address parameter is 
analyzed to identify the node towards which the message should be sent. The NSDU is then included as 
user data in a Unitdata (UDT) message, which is sent towards the node using the MTP functions. Upon 
receipt of the UDT message, the SCCP functions at that node perform the routing analysis as described 
in Section 2 of this Recommendation and, if the destination of the UDT message is a local user, deliver 
the NSDU to the local higher layer functions. If the Called Party Address is not at that node, then the 
UDT message is forwarded to the next node. This process continues until the NSDU has reached the 
Called Party Address. | 


1.4 Structure of the SCCP and contents of specification. 


The basic structure of the SCOP appears in Figure 1/Q.714. It consists of four functional blocks as 
follows. 


a. SCCP connectton-ortented control: its purpose is to control the establishment and release of 
signalling connections and to provide for data transfer on signalling connections. 


b. SCCP connectionless control: 1ts purpose is to provide for the connectionless transfer of data 
units. 


c. SCCP management: its purpose is to provide capabilities, in addition to the Signalling Route 
Management and flow control functions of the MTP, to handle the congestion or failure of either 
the SCCP user or the signalling route to the SCCP user. 


d. SCCP routing: upon receipt of a message from the MTP or from functions a, b, or c above, SCCP 
routing provides the necessary routing functions to either forward the message to the MTP for 
transfer, or pass the message to functions a, b, or c above. A message whose Called Party Address 
is a local user is passed to functions a, b, or c, while one destined for a remote user 1s forwarded to 
the MTP for transfer to a distant SCCP user. 


Section 2 of this specification describes the addressing and routing functions performed by the 
SCCP. Section 3 specifies the procedures for the connection-oriented services (protocol classes 2-4). 
Section 4 specifies the procedures for the connectionless services (protocol classes 0 and 1). Section 5 
specifies the SCCP management procedures. 


*& 
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2. ADDRESSING AND ROUTING 
2.1 SCCP Addressing. 


The Called and Calling Party Addresses contain the information necessary for the SCCP to 


determine an origination and destination user, respectively. In the case of the connection-oriented 
procedures, the addresses are the origination and destination points of the signalling connection, while 
in the case of the connectionless procedures, the addresses are the origination and destination points of 
the message. : 


When transferring connection-oriented or connectionless messages, two basic categories of address 


are distinguished by SCCP routing: 


1. 


Global Title - A global title is an address, such as a DPC or dialed-digits, which does not explicitly 
contain information that would allow routing in the signalling network, that is the translation 
function of the SCCP is required. This translation function could be performed on a distributed 
basis or on a centralized basis. The last case, where a request for translation is sent to a 
centralized data base while waiting for the response is for further study. 


DPC + SSN - A Destination Point Code and Subsystem Number allow direct routing by the SCCP 
and MTP, that is, the translation function of the SCCP is not required. In the called address, the 
point code used is the DPC in the routing label. In the calling address, the point code is either 
supplied by the Calling Party Address parameter, or if not present there, by the OPC. 


If a reply or a message return is required, the Calling Party Address plus the OPC in the 
routing label must contain sufficient information to uniquely identify the originator of the 
message. If the message requires global title translation where the OPC may change, then the 
Calling Party Address should not contain a SSN only. 


SCccP 
Users 


Management 
(SCMG) 


MTP 


Figure 1/Q.714. SCCP Overview 


2.2 SCCP Routing Principles. 


SCCP Routing Control receives messages from the Message Transfer Part for routing and 


discrimination, after they have been received by the MTP from another node in the signalling network. 
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SCOP Routing also receives internal messages from SCCP Connection-oriented and Connectionless 
Control and performs any necessary routing functions (e.g. address translation) before passing them to 
the MTP for transport in the signalling network. SRC may also translate (e.g. for security reasons) a 
Calling party Address from PC + SSN to GT. This function is optional depending on the security 
requirements of network interconnections. 


2.2.1 Message Received From MTP A message received from the MTP that requires routing will 
include the Called Party Address parameter giving information for routing the call. These messages 
include the Connection Request message, and all types of Connectionless messages. Other messages 
either have no Called Party Address or give the Called Party Address for information purposes only, 
and are passed to connection-oriented control for processing. 


If the Called Party Address parameter is used for routing, it shall take one of the following values. 


1. Subsystem Number only - This indicates that the receiving SCCP is the termination point of the 
message. The SSN is used to determine the local subsystem. 


2. Global Title only - This indicates that translation is required. Translation of the Global Title 
results in a new DPC for routing the message, and possibly a new SSN or GT or both in the Called 
Party Address. 


3. SSN + GT - In this case, the address type information is used to determine whether the SSN or 
the GT should be used for routing and processing as in items 1 and 2 above. 


2.2.2 Message from Connection-Oriented or Connectionless Control Addressing information, 


indicating the destination of the message, is included with every internal message received from 
connection-oriented or connectionless control. For connectionless messages, this addressing information 
is obtained from the Called Address parameter associated with the N-UNITDATA request primitive. 
For connection-oriented messages received by SCCP routing during the connection establishment phase, 
the addressing information is obtained from the Called Address parameter associated with the N- 
CONNECT request primitive. During the data transfer or connection release phases, the addressing 
information (i.e., the DPC) is that associated with the connection section. 


The addressing information can take the following forms: 
DPC 

DPC + (SSN or GT or both), 

GT | 

GT + SSN. 


The first form applies to connection-oriented messages during the data transfer and connection 
release phases. The last three forms apply to connectionless messages and to the Connection Request 
message. 


2.2.2.1 DPC Routing If the DPC is present in the addressing information then the DPC is used in 
the routing label and: 


md WD bb = 


1. If no other addressing information is available, no Called Party Address is provided; 


2. if SSN or GT or both are available, this information is used in the Called Party Address with an 
indication of which one is to be used for routing. 


If the DPC 1s the node itself, the information is passed to connection-oriented or connectionless 
control, as if it had been received from the MTP. 


* + * &% % + & ¥ 
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2.2.2.2 Global Title Translation If the DPC is not present, then a global title translation is 
required before the message can be sent out. Translation results in a DPC and possibly a new SSN or 
new GT, or both. The routing procedures then continue as In section 2.2.2.1. | 


2.3 SCCP Routing. 


The SCCP routing functions are based on information contained in the Called Party Address. The 
Address consists of the Address indicator and Address fields. 


In this section, “unavailable” encompasses all reasons why it may not. be possible to transfer a 
message to a signalling point or subsystem. Included are failure, congestion, and unequippedness. 


2.3.1 Receipt of a Message Transferred by the MTP One of the following actions is taken by 
SCCP routing upon receipt of a message from the Message Transfer Part. The message is received by 


the SCCP when the MTP invokes an MTP-TRANSFER indication: 


1. If the message is not a Connection Request, Unitdata or Unitdata Service message, then SCCP 
routing passes the message to connection-oriented control. 


2. If the Called Party Address indicates that routing on subsystem number is desired, then SCOP 
routing checks the status of the subsystem: 


a. If the subsystem is available, the message is passed, based on the message type, to either 
connection-oriented control or connection-less control. 


b. If the subsystem is unavailable and 
— the message is a connectionless message, then the return procedure is initiated. 
— the message is a connection-oriented message, then the refusal procedure is initiated. 


In addition, if the subsystem is failed, SCCP management is notified that a message 
was received for a failed subsystem. 


3. If the Called Party Address indicates that routing on global title is desired, a translation of the 
global title must be performed. 


a. If the translation of the global title does not exist, and: 
— the message is a connectionless message, then the message return procedure is initiated; 


— the message is a connection-oriented message, then the connection refusal procedure is 
initiated. 


b. If the translation of the global title exists and both the DPC and subsystem number (SSN) 
are determined, then: 


1. if the DPC is the node itself, then the procedures in 2 above are followed. 


2. if the DPC is not the node itself, the DPC and SSN are available, and the message is a 
connectionless message, then the MTP-TRANSFER request primitive is invoked. 


3. if the DPC is not the node itself, the DPC and SSN are available, and the message is a 
connection-oriented message, then: 


a. if an association of connection sections is required, the message is passed to 
connection-oriented control; 


b. if no association of connection sections is required, the MTP-TRANSFER request 
primitive is invoked; 
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4. if the DPC is not the node itself, and the DPC and/or SSN are not available and 


a. the message is a connectionless message, the message return procedure is then 
initiated; 


b. the message is a connection-oriented message, then the refusal procedure is 
initiated. 


c. Ifthe translation of the global title exists, and only a DPC or DPC + new GT is determined, 
then: 7 


1. If the DPC is available, and the message is a connectionless message, then the MTP- 
TRANSFER request primitive is invoked; 


2. if the DPC is available, and the message is a connectionless message then 


— If an association of the connection sections is required, then the message is passed 
to connection-oriented control; 


— If no association of connection sections is required, then the MTP-TRANSFER 
request primitive is invoked; 


3. If the DPC is not available and 
— the message is a connectionless message, then the message return procedure is 
initiated; 
— the message is a connection-oriented message, then the connection refusal 


procedure is initiated. 


2.3.2 Receipt of Message from Connectionless or Connection-Oriented Control. One of the 
following actions is taken by SCCP Routing upon receipt of a message from connectionless control or 
connection-oriented control. 


1. If the message is a Connection Request message at an intermediate node (where connection 
sections are being associated), and 


a. the DPC is available, then the MTP-TRANSFER request primitive is invoked; 
b. the DPC is not available, then the connection refusal procedure is initiated via SCOC. 
2. Ifthe message is a connection-oriented message other than a Connection Request message, and 
a. the DPC is available, then the MTP-TRANSFER request primitive is invoked; 
b. the DPC is not available, then the release procedure is initiated. | 


3. If the primitive associated with a Connection Request or connectionless message includes a DPC, 
and the routing indicator indicates route on SSN, and 


a. the DPC is the node itself, then the procedures in section 2.3.1.2 are initiated. 


b. the DPC is not the node itself and the DPC and SSN are available then the MTP- 
TRANSFER request primitive is invoked.” 


2. Note that association of connection sections is not required, as this is the origination node of the message. 


TR-NPL-000246 
Issue 1, 1985 
Revision 3, June 1989 


SIGNALLING CONNECTION CONTROL PART PROCEDURES Q.714 


c. the DPC is not the node itself and the DPC and/or SSN are not available, then 
— for connectionless messages, the message return procedure is initiated; 
— for connection-oriented messages, the refusal procedure is initiated. 


4. If the primitive associated with a Connection Request or a connectionless message includes a DPC 
and the routing indicator indicates route on global title, and 


a. the DPC is the node itself, then the procedures in 2.3.2.5 are followed. 
b. the DPC is not the node itself, and the DPC is available, then the MTP-TRANSFER request 


primitive is invoked. 
-c. the DPC is not the node itself, and the DPC is not available and 
— the message is a connectionless message, then the return procedure is initiated. 
— the message is a connection-oriented message, then the refusal procedure is initiated. 


5. If the primitive associated with a Connection Request or a connectionless message does not include 
a DPC and the routing indicator indicates route on global title, then a translation of the global 
title must be performed. 


a. Ifthe translation of the global title does not exist, and: 
— the message is a connectionless message, then the message return procedure is initiated. 


— the message is a connection-oriented message, then the connection refusal procedure is 
initiated. 


b. Ifthe translation of the global title exists, and both the DPC and SSN are determined, then: 
1. if the DPC is the node itself, the procedures in 2.3.1.2 above are then followed; 


2. if the DPC is not the node itself, and the DPC and SSN are available, the MIF- 
TRANSFER request primitive is then invoked;® 


3. if the DPC is not the node itself, and the DPC and/or SSN are not available and 


a. the message is a connectionless message, then the message return procedure is 
Initiated. 


b. the message 1s a connection-oriented message, then the refusal procedure is 
initiated. 


c. Ifthe translation of the global title exists, and the DPC or DPC + new GT is determined, 
then: 


1. If the DPC is available then the MTP-TRANSFER request primitive is invoked. 
2. If the DPC is not available and 


a. the message is a connectionless message, then the message return procedure is 
initiated; 


3. Note that association of connection sections is not required, as this is the origination node of the message. 
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b. the message is a connection-oriented message, then the refusal procedure is 
initiated. 


2.4 Routing failures. 


The SCCP recognizes a number of reasons for failure in SCCP routing control. Examples of these 
reasons are: 


translation does not exist for addresses of this nature, 
translation does not exist for this address, 
network failure, 


network congestion, and 


unequipped user. 
The precise classification of the causes by which such failures are recognized is for further study. 


When SCCP routing is unable to transfer a message due to the unavailability of a Point Code or 
Subsystem, one of the above reasons is indicated in the Connection Refused message or the Unitdata 
Service message. 


3. CONNECTION-ORIENTED PROCEDURES 


Text temporarily removed. 


4, CONNECTIONLESS PROCEDURES 


The connectionless procedures allow a user of the SCCP to request transfer of up to 255 octets* of 
user data without first requesting establishment of a signalling connection. 


The N-UNITDATA request and indication primitives are used by the user of the SCCP to request 
transfer of user data by the SCCP and for the SCCP to indicate delivery of user data to the destination 
user. Parameters associated with the N-UNITDATA request primitive must contain all information 
necessary for the SCCP to deliver the user data to the destination. 


Transfer of the user data is accomplished by including the user data in Unitdata messages. 


When the user of the SCCP requests transfer of user data by issuing a N-UNITDATA request 
primitive, there are two classes of service that can be provided by the SCCP, protocol classes 0 and 1. 
These protocol classes are distinguished by their message sequencing characteristics. 


When the user of the SCCP requests transfer of several messages by issuing multiple N- 
UNITDATA request primitives, the the probability of these messages being received in sequence at the 
Called Address depends on the protocol class designated in the request primitives. For protocol class 0 
the sequence control parameter is not included in the N-UNITDATA request primitive and the SCCP 
may generate a different SLS for each of these messages. For protocol class 1 the sequence control 
parameter is included in the N-UNITDATA request primitive and, if the parameter is the same in each 
request primitive, then the SCCP will generate the same SLS for these messages. 


4. The transfer of up to 255 octets of user data is allowed depending on the maximum length of signal units chosen for the 
network as specified in Q.703. 
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The Message Transfer Part retains message sequencing for those messages with the same SLS field. 
The Signalling Connection Control Part relies on the services of the MTP for transfer of SCCP 
messages. Based on the characteristics of the MTP, the protocol class 1 service may be used in such a 
way that it provides a quality of service that has a lower probability of out-of-sequence messages than 
that provided by protocol class 0. 


4.1 Data transfer 


The N-UNITDATA request primitive is invoked by the SCCP user at an originating node to request 
connectionless data transfer service. The connectionless data transfer service is also used to transport 
SCCP management messages, which are transferred in the user data field of Unttdata messages. 


The Unitdata message is then transferred, using SCCP and MTP routing functions, to the Called 
Address indicated in the N-UNITDATA request primitive. 


SCCP routing and relaying functions may be required at intermediate nodes, since complete 
translation and routing tables for all addresses are not required at every node. 


When the Unitdata message can not be transferred to its destination, the message return function 
may be initiated. 


The SCCP uses the services of the MTP and the MIP may, under severe network conditions, 
discard messages. Therefore, the user of the SCCP may not always be informed of nondelivery of user 
data. The MTP notifies the SCCP of unavailable or congested signalling points using the MTP-PAUSE 
and MTP-STATUS indications. The SCCP then informs its users. 


When a Unttdata message is received at the destination node, an N-UNITDATA indication 
primitive is invoked. Because SCCP management messages are transferred using the connectionless 
data transfer service, these messages must be identified prior to invoking the N-UNITDATA primitive. 


4.2 Message return. 


The purpose of message return is to discard or return messages which cannot be delivered to their 
final destination. 


The message return procedure is initiated if SCCP routing is unable to transfer a Unttdata or 
Unitdata Service message. The procedure may be initiated, for example, as a result of insufficient 
translation information or the inaccessibility of a subsystem or point code. Specific reasons are 
enumerated in Section 2.3. 


a. If the message is a Unitdata message, and 


— the option field is set to return, then a Unttdata Service message is transferred to the Calling 
Party Address. 


— the option field is not set to return, the message is then discarded. 
b. Ifthe undeliverable message is a Untidata Service message, it is discarded. 


The user data field of the Unitdata message and the reason for return are included in the Unttdata 
Service message. 


When a Unitdata Service message is received at the destination node, an N-NOTICE indication 
primitive is invoked. 


4.3 Syntax Error. 


This type of error occurs when a node receives a message that does not conform to the format 
specifications of the SCCP. Examples of syntax errors are: | 
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1. Unreasonable pointer value (e.g. points beyond the end of the message) 
2. Mismatch between type and protocol class parameters 
3. Inconsistent address indicator and address contents. 


When a syntax error is detected for a connectionless message, the message is discarded. Checking for 
syntax errors beyond the processing required for SCCP connectionless message routing is not 
mandatory. 


5. SCCP MANAGEMENT PROCEDURES 
5.1 General. 


The purpose of SCCP management is to provide the procedures necessary to maintain network 
performance by rerouting or throttling traffic in the event of failure or congestion in the network. 


Although SCCP Management has its own SSN, these procedures do not apply to it. 


SCCP management is organized into three subfunctions: Signalling point status management and 
subsystem status management allow SCCP management to use information concerning the availability 
of point codes and subsystems, respectively, to allow the network to adjust to failure, congestion, and 
recovery in the network. Traffic information management provides a means for SCCP users to know 
received traffic patterns. 


SCCP management procedures rely on signalling point and signalling link failure, recovery, and 
congestion information provided in the MITP-PAUSE, MTP-RESUME and MTP-STATUS indication 
primitives as well as on subsystem failure and recovery information found in SCCP management 
messages’. Management information is transferred using SCCP connectionless service with no return 


requested. Formats of these messages appear in Q.713. 


The information pertaining to both single and replicated subsystems or nodes is used for 
management purposes. In particular, this allows a Called Party Address which is specified in the form 
of a global title to be translated to different point codes and/or subsystem numbers depending on the 
status of the network or SCCP subsystems. 


Nodes or subsystems that are replicated may relate to their replicates in one of several ways. 
("Replicate” is a term meaning “multiple copies” and may be used to generically describe either mode 
below. A node or subsystem that is not replicated is termed "solitary”.) 


The first mode uses a concept of dominance. Traffic is split among several subsystems. Under 
normal conditions, each portion of the traffic is routed to a preferred, or “primary”, system. When the 
primary system fails, this traffic is routed to a "backup” system. When the primary system recovers, it 
reassumes its normal traffic load. 


A second mode uses a replacement concept. Consider two systems, A and B, which are 
“alternates”. When A fails, its traffic is routed to B; but when A recovers; the traffic is not moved back 
to A. It is only when B fails that traffic is shifted to A. In addition, other modes are possible. 


The current SCCP management procedures are designed to manage replicated nodes and 


subsystems that operate in a dominant mode and for which any given primary system has only one 


5. Subsystem congestion control is for further study. 


-10- 
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backup (i.e., duplicated subsystems). Management procedures for subsystems which operate in a mode 
other than the dominant mode and which have more than one backup are for further study. 


SCCP management procedures utilize the concept of a “concerned” subsystem or signalling point. 
In this context, a “concerned” entity means an entity with an immediate need to be informed of a 
particular signalling point/subsystem status change, independently of whether SCCP communication is 
in progress.between the “concerned” entity and the affected entity at the time of the status change. 


In the following procedures, the term “adjacent” is understood to include logical adjacency. That 
is to say that node A is adjacent to node B if any SS7 path exists from A to B without a global title 
translator node in the path. 


The signalling point prohibited, signalling point allowed and signalling point congested 
procedures, specified in 5.2.2, 5.2.3, and 5.2.4 respectively, deal with the accessibility of a signaling 
point. 


The subsystem prohibited and subsystem allowed procedures, detailed in 5.3.2 and 5.3.3, 
respectively, deal with the accessibility of a subsystem. 


An audit procedure to ensure that necessary subsystem management information is always 
available is specified in the subsystem status test procedure outlined in 5.3.4. 


A subsystem may request to go out of service using the coordinated state change control procedure 
specified in 5.3.5. 


Local subsystems are informed of any related subsystem status by the local broadcast procedure 
specified in 5.3.6. 


Concerned signalling points are informed of any related subsystem status by the broadcast 
procedure specified in 5.3.7. 


Information regarding traffic patterns an SCCP user receivers is provided by the traffic mix 
procedures outline in 5.4.2, 5.4.3 and 5.4.4. All procedures related to traffic mix information are 
optional, and included for information only. 


5.2 Signalling point status management. 


5.2.1 General. Signalling point status management allows routing and translation tables to be 
updated in a manner which best allows that network to adjust to and compensate for failure, 
congestion, or recovery of signalling points. 


5.2.2 Point code prohibited. When SCCP management receives an MTP-PAUSE indication relating 
to a destination that has failed, SCCP management 


1. marks its translation table 
— “translate to backup node” if that point code has a backup. 


— “translate to backup subsystem” for each replicated subsystem at that point code if the 
“subsystem has a backup. 


2. marks the status as 
— “prohibited” for that point code. 
— “prohibited” for each subsystem at that point code. 


3. Discontinues any subsystem status tests (see 5.3.4) it may be conducting to any subsystems at 
that signalling point. 
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4. Initiates a local broadcast (see 5.3.6) of ”“User-out-of-service” information for each subsystem at 
that signalling point. : 


5. Sends a Subsystem-Backup-Routing message regarding each duplicated subsystem at that 
signalling point to SCCP. management at the location of the corresponding backup subsystem. 
(This action is taken only if the node receiving the MTP-PAUSE is a “translator node” that is 
adjacent to the node at which the backup subsystem is located. For example, a signalling transfer 
point that learns that an adjacent database has failed sends a Subsystem-Backup-Routing Message 
to SCCP management for each backup subsystem at the backup database. If the signalling 
transfer point is not adjacent to the allowed backup subsystem, it does not send Subsystem- 

. Backup-Routing messages.) (Optional) 


£ 


6. Marks all local equipped duplicated subsystems backup routed from the failed signalling point, if 
the failed signalling point is an adjacent translator node. (Optional) 


7. Initiates the traffic-mix information procedure (see 5.4.2.1.1) to the local allowed users if the failed 
signalling point is an adjacent translator node. (Optional) 


8. Informs local concerned subsystems of the status of that signalling point.® 


5.2.3 Point code allowed. When SCCP management receives an MTP-RESUME indication relating 
to a destination that has recovered from failure, SCCP management 


1. resets the congestion level for that signalling point 
2. marks its translation table 

— “translate to primary node” if that node has a backup. 
3. marks the status as 

— “allowed” for that point code. 


4, Initiates the subsystem status test procedure (see 5.3.4) with affected subsystems at that signalling 
point. 


5. Initiates, if the recovered signalling point is an adjacent translator node, (Optional) 


a. The subsystem routing status test procedure (sée 5.4.4) for all local equipped duplicated 
subsystems. 


b. The traffic-mix information procedure (see 5.4.2.1.1) to the local allowed subsystems. 
6. Informs local concerned subsystems of the status of that signalling point.® 


5.2.4 Signalling Point Congested. When SCCP management receives an MTP-STATUS indication 
relating to signalling network congestion to a signalling point, SCCP management 


1. Updates that signalling point status to reflect the congestion 


2. Notifies local concerned subsystems of network congestion to that signalling point? 


6. The criteria and methods for notification to local subsystems are for further study. 
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5.3 Subsystem status management. 


5.3.1 General. Subsystem status management updates routing and translation tables based on the 
information of failure, withdrawal, congestion and recovery of subsystems. This allows alternative 
routing to backup subsystems. Local users are informed of the status of their backup subsystems. 


5.3.2 Subsystem prohibited. 


5.3.2.1 Receipt of message for a prohibited subsystem. If SCCP routing control receives a 
message for a prohibited local subsystem, SCCP routing control invokes subsystem prohibited control. 
A Subsystem-Prohibited message is sent to SCCP management at the originating point code if the 
originating subsystem is not local; the OPC is determined from the routing label of the received 
message. 


5.3.2.2 Receipt of Subsystem-Prohibited message or subsystem failure. Under one of the 
following conditions: 


a. SCCP management receives a Subsystem-Prohibited message about a subsystem marked allowed, 


b. a N-STATE request primitive with “User-out-of-service” information is invoked by a local 
subsystem marked “allowed”, or 


c. SCCP management detects that a local subsystem has failed, 
then SCCP management does the following: 
1. marks its translation table (in entries where the affected subsystem is the primary) 
— “translate to backup subsystem” if a backup subsystem exists for the prohibited subsystem. 
2. marks the status as 
— “prohibited” for that subsystem. 


3. initials a local broadcast (Section 5.3.6) of “user-out-of-service” information for the prohibited 
subsystem. 


4. initiates the subsystem status test procedure (Section 5.3.4) if the prohibited subsystem is not 
local. 


5. forwards the information throughout the network by 


— sending a Subsystem-Prohibited message to the backup of the prohibited subsystem if the 
backup subsystem is allowed and is located at an adjacent node. (This may be included in 
the broadcast procedure). 


— initiating a broadcast of Subsystem-Prohibited messages to concerned signalling points. 
6. sends 


— a Subsystem-Backup-Routing message to the backup of the prohibited subsystem if the 
backup subsystem is allowed (This action is taken only if the prohibited subsystem is located 
at an adjacent node.) (This item is for further study.) 


7. cancels “ignore subsystem status test” and the associated timer if they are in progress and if the 
prohibited subsystem resides at the local node. 


5.3.3 Subsystem allowed. 
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5.3.3.1 Receipt of Subsystem-Allowed message or N-STATE request primitive. Under one of 
the following conditions: _ 


a. SCCP management receives a Subsystem-Allowed message about a subsystem marked prohibited, 
or 


b. the N-STATE request primitive with “User-in-Service” information is invoked by a subsystem 
marked “prohibited”, 


then SCCP management does the following: 
1. marks its translation table (in entries where the affected subsystem is the primary) 
| — "translate to primary subsystem” if a backup subsystem exists for the allowed subsystem. 
2. marks the status as 
— “allowed” for that subsystem. 


3. initiates a local broadcast (Section 5.3.6) of “user-in-service” information for the allowed 
subsystem. 


4. discontinues the subsystem status test relating to that subsystem if such a test was in progress. 
5. forwards the information throughout the network by | 


— sending a Subsystem-Allowed message to the backup of the allowed subsystem, if the backup 
subsystem is located at an adjacent node. (This may be included in the broadcast 
procedure.) 


— initiating a broadcast of Subsystem-Allowed messages to concerned signalling points. 
6. sends 


— Subsystem-Normal-Routing to the backup of the newly allowed subsystem. (This action is 
taken only if the allowed subsystem is located at an adjacent node.) (This item is optional 
only.) | | 


5.3.4 Subsystem status test. 


5.3.4.1 General. The subsystem status test procedure is an audit procedure that verifies the status of 
subsystems marked prohibited. 


5.3.4.2 Actions at the initiating node. A subsystem status test is initiated by other SCCP 
management procedures when 


a. asSubsystem-Prohibited message is received, or 
b. an MTP-RESUME indication primitive for a previously failed point code is invoked. 


A subsystem status test associated with a failed subsystem is commenced by starting a timer (stat. 
info) and marking a test in progress. No further actions are taken until the timer expires. 


Upon expiration of the timer, a Subsystem-Status-Test message is sent to SCCP management at 
the node of the failed subsystem and the timer is reset. 


The cycle continues until the test is terminated by another SCCP management function at that 
node. Termination of the test causes the timer and the test mark to be canceled. 
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5.3.4.3 Actions at the receiving node. When SCCP management receives a Subsystem-Status-Test 
message, and there is no “ignore subsystem status test” in progress it checks the status of the named 
subsystem. If the subsystem is allowed, a Subsystem-Allowed message is sent to SCCP management at 
the node conducting the test. If the subsystem is prohibited, no reply is sent. 


5.3.5 Coordinated state change. 


5.3.5.1 General. A subsystem may be withdrawn from service without degrading the performance of 
the network by using the coordinated state change procedure. 


5.3.5.2 Actions at the requesting node. When a replicated subsystem wishes to go out of service, it 
invokes an N-COORD request primitive. SCCP management at that node sends a Subsystem-Out-of- 
Service-Request message to the backup subsystem, sets a timer (coord.chg) and marks the subsystem as 
“waiting for grant”. 


Arrival of a Subsystem-Out-of-Service-Grant message at the originating SCCP management causes 
the timer to be canceled, the “waiting for grant” state to be canceled, and an N-COORD confirmation 
primitive to be invoked to the originating subsystem. Subsystem Prohibited messages are broadcasted 
(Section 5.3.7). An ignore subsystem status test timer is started and the subsystem is marked as 
"ignore subsystem status test.” Subsystem status tests are ignored until the “ignore subsystem status 
test” timer expires or the marked subsystem involves an N-STATE request primitive with ”“User-out-of- 
service” information. If no “waiting for grant” is associated with the subsystem named in the 
Subsystem-Out-of-Service-Grant message, the Subsystem-Out-of-Service-Grant message is discarded. 


If the timer associated with the subsystem waiting for the grant expires before a Subsystem-Out- 
of-Service-Grant message is received, the “waiting for grant” is canceled and the request is denied by 
sending an N-COORD primitive indicating denial. 


5.3.5.3 Actions at the granting node. When the SCCP management at the node at which the 
backup subsystem is located receives the Subsystem-Out-of-Service-Request message, it checks the 
status of local resources. If the SCCP has sufficient resources to assume the increased load, it invokes 
an N-COORD indication primitive to the backup subsystem. If the SCCP does not have sufficient 
resources, no further action 1s taken. 


If the backup subsystem has sufficient resources to allow its mate to go out of service, it informs 
SCCP management by invoking an N-COORD request primitive. A Subsystem-Out-of-Service-Grant 
message is sent to the originating node. If the backup subsystem does not have sufficient resources, no 
reply is returned. 


5.3.8 Local broadcast. 


5.3.6.1 General. The local broadcast procedure provides a mechanism to inform local SCCP 
subsystems of any related subsystem status information received. 


5.3.6.2 User-out-of-service. A local broadcast of ”“User-out-of-service” information is initiated by 
other SCCP management procedures when 


a. asSubsystem-Prohibited message is received, or 

b. an N-STATE request primitive with “User-out-of-service” information is invoked, or 

c. alocal subsystem failure is detected by SCCP management, or 

d. an MTP-PAUSE indication primitive Sqeceed. ) 


SCCP management then informs all local allowed SCCP subsystems about the subsystem failure 
by invoking an N-STATE indication primitive with ”“User-out-of-service” information. 
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rice. A local broadcast of “subsystem-in-service” information is initiated by other 
=rocedures when 


“owed message is ‘received, or 
‘:quest primitive with ”User-in-service” information is invoked. 


aent then informs all local allowed SCCP subsystems, except the newly allowed one, 
3 recovery by invoking an N-STATE indication primitive with “User-in-service” 


The broadcast procedure provides a mechanism to inform concerned signalling 
subsystem status at local or adjacent point codes. 


; prohibited. A broadcast of Subsystem-Prohibited messages is initiated by other 
yrocedures when 


rohibited message is received, or 

equest primitive with “User-out-of-service” information is invoked, or 

-m failure is detected by SCCP management, or 

ut-of-Service-Grant message arrives for a subsystem marked “waiting for grant”. 


nent does nothing if the signalling point where the prohibited subsystem is located 
: informer signalling point from which the SCCP message is received. Otherwise, 
informs all concerned signalling points, except the informer signalling point, about 
> by Subsystem-Prohibited messages. 


allowed. A broadcast of Subsystem-Allowed messages is initiated by other SCCP 
ires when 


lowed message is received, or 
2quest primitive with "User-in-service” information is invoked. 


nent does nothing if the signalling point where the allowed subsystem is located is 
nformer signalling point from which the SCCP message is received. Otherwise, 
nforms all concerned signalling points, except the informer signalling point, about 
ry by Subsystem-Allowed messages. | 


ation management. 
1 this section are optional and provided for information only. 


»system routing status management procedures provide a mechanism for informing 
ed traffic patterns as described in Q.711. 


procedures There is one mix procedure, which is invoked when local users are 
consequences of 


unavailable 
available 


to subsystem, or 
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d. backup routing to subsystem. 


The traffic pattern is determined by analyzing the status of adjacent nodes, the status of backup 
subsystems, and the routing flag. 


The analysis is performed on the basis of node category. Thus, there are six specific procedures 
for each node category. Each set of procedures at a given node uses the same method of determining 
the traffic pattern; these methods are specified in Section 5.4.3. 


Node category serves to differentiate the position and function of a node in the network. “End- 
node/database” and “intermediate-node/translator” are two examples. 


. 5.4.2.1 End-Node/Database 


5.4.2.1.1 Traffic-Mix Information. SCCP management may invoke an N-TRAFFIC indication 
primitive with ”Traffic-mix” information to each local concerned user, when one of the following occurs: 


1) The MTP invokes an MTP-PAUSE indication primitive 
) The MTP invokes an MTP-RESUME indication primitive | 

) A Subsystem-Backup-Routing message is received by SCCP management 
4) A Subsystem-Normal-Routing message is received by SCCP management 


An N-STATE request primitive with “User-in-Service” information is invoked by a 
subsystem marked prohibited. 


5.4.2.2 Subsystem backup routing. Upon receipt of a Subsystem-Backup-Routing message, SCCP 
management 


1. marks the routing flag associated with 


a. the signalling transfer point from which the Subsystem-Backup-Routing message was 
received, and 


b. the subsystem to which the message refers 
to “backup”. 
2. initiates a subsystem routing status test. 
3. initiates a traffic mix information procedure to the affected local user if it’s allowed. 
5.4.2.3 Subsystem normal routing. | 


5.4.2.3.1 End-node/database. Upon receipt of a Subsystem-Normal-Routing message, SCCP 
management 


1. marks the routing indicator associated with 


a. the signalling transfer point from which the Subsystem-Normal-Routing message was 
received, and 


b. the subsystem to which the message refers 
to “normal”. 
2. stops the subsystem routing status test. 


3. Initiates a traffic mix information procedure to the affected local user if it’s allowed. 
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5.4.3 Calculation of traffic-mix information. 


5.4.3.1 General. The quasi-associated network (see Recommendation Q.705, Annexes 1 and 2) uses 
one piece of additional information called the routing flag. The routing flag provides additional network 
connectivity information. Two network-specific messages, Subsystem-Backup-Routing and Subsystem- 
Normal-Routing, allow the value (i.e., “backup” or “normal”) of the routing flag to be determined. 


Subsystem routing status messages are sent only by intermediate nodes adjacent to the end node 
at which a subsystem has become recovered or prohibited. When SCCP management marks a 
subsystem “translate to backup subsystem”, a Subsystem-Backup-Routing message is sent to the SCCP 
management associated with the backup subsystem. When SCCP management marks a subsystem 
"translate to primary subsystem” and the backup is allowed, a Subsystem-Normal-Routing message is 
transferred to the SCCP management associated with the backup subsystem. 


5.4.3.2 End-node/database. The method of determining the traffic pattern received by a local user 
at an “end-node/database” is summarized in Figure 18/Q.714. The possible failure combinations upon 
which this method is based are shown in Figure 19/Q.714. 


Traffic-mix information is currently provided only at “end-node/databases”. 
5.4.4 Subsystem routing status test. 


5.4.4.1 General. The subsystem routing status test procedure is an audit procedure which provides 
recovery from a lost Subsystem-Normal-Routing message. 


5.4.4.2 Actions at the initiating node. A subsystem routing status test is initiated by the 
subsystem routing status procedure when a Subsystem-Backup-Routing message is received. 


A subsystem routing status test associated with a subsystem is commenced by starting a timer 
(rtg.stat.info) and marking a test in progress. No further actions are taken until the timer expires. 


Upon expiration of the timer, a Subsystem-Routing-Status-Test message is sent to SCCP 
management at the node from which the Subsystem-Backup-Routing message was received, and the 
timer is restarted. 


The cycle continues until the test is terminated by another SCCP management function at that 
node. Termination of the test causes the timer and the test mark to be canceled. 


5.4.4.3 Actions at the receiving node. When SCCP management receives an SRT message, it 
checks the status of the routing flags. If the routing is normal, a Subsystem-Normal-Routing message is 
sent to SCCP management at the node conducting the test. If there is backup routing, no reply is sent. 


6. STATE TRANSITION DIAGRAMS 
6.1 General. 


This section contains the description of the signalling network functions described in Sections 2 
through 5 according to the CCITT Specification and Description Language. 


A set of diagrams is provided for each of the following major functions: 
a. SCCP routing control (SCRC), described in Section 2. 
—b. SCCP connectionless control (SCLC), described in Section 4; and 
c. SCCP management (SCMG), described in Section 5. 


For each major function, a figure illustrates a subdivision into functional specification blocks, 
showing their functional interactions as well as the interactions with the other major functions. In each 
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case, this is followed by figures showing state transition diagrams for each of the functional specification 
blocks. 


The detailed functional breakdown shown in the following diagrams is intended to illustrate a 
reference model, and to assist interpretation of the text in the earlier section. The state transition 
diagrams are intended to show precisely the behavior of the signalling system under normal and 
abnormal conditions as viewed from a remote location. It must be emphasized that the functional 
partitioning shown in the following diagrams is used only to facilitate understanding of the system 
behavior, and is not intended to specify the functional partitioning to be adopted in a practical 
implementation of the signalling system. 


6.2 Drafting conventions. 
Each major function is designated by its acronym (e.g., SCMG = SCCP management). 


Each functional block is designated by an acronym which identifies it (e.g., SSAC = Subsystem 
allowed control). 


External inputs and outputs are used for interactions between different functional blocks. 
Included within each input and output symbol in the state transition diagrams are acronyms that 
identify the functions which are the source and destination of the message, e.g.,: 


SSAC — SSTC indicates that the message is sent within a functional level 
from: subsystem allowed control 6 
to: subsystem status test control 


Internal inputs and outputs are only used to indicate control of time-outs. 
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6.3 Abbreviations and Timers. 


Abbreviations and timers used in paeunes 1/Q.714 to 19/Q.7 14 are listed below. 
APNB - All-primary/No-backup 
APSB - All-primary/Some-backup 
APAB - All-primary/All-backup 
BOST - Broadcast 
CL - Connectionless 
CO - Connection-oriented 
CSCC - Coordinated State Change Control 
DPC - Destination Point Code 
DSN - Destination Subsystem Number 
GT - Global Title 
MTC - Message Type Code 
MTP - Message Transfer Part 
NPNB - No-primary/No-backup 
PATI - Point Code Allowed Traffic Information 
PC - Point Code 
PCAC - Point Code Allowed Control 
POPC - Point Code Prohibited Control 
PPTI - Point Code Prohibited Traffic Information 
RFSL - Refusal 
SATI - Subsystem Allowed Traffic Information 
SBRC - Subsystem Backup Routing Control 
SBR - Subsystem-Backup-Routing 
SCLC - SCCP Connectionless Control (formerly CLMD) 
SCMG - SCCP Management 
SCOC - SCCP Connection-Oriented Control (formerly SCDC) 
SORC - SCCP Routing 
SLS - Signaling Link Selection 
SNR - Subsystem-Normal-Routing 
SNRC - Subsystem Normal Routing Control 
SOG - Subsystem-Out-of-Service-Grant 
SOR - Subsystem-Out-of-Service-Request 
SPTI - Subsystem Prohibited Traffic Information 
SPNB - Some-primary/No-backup 
SPSB - Some-primary/Some-backup 
SRT - Subsystem-Routing-Test 
SRTC - Subsystem Routing Status Test Control 
SSA - Subsystem-Allowed 
SSAC - Subsystem Allowed Control 
SSN - Subsystem Number 
SSP - Subsystem-Prohibited 
SSPC - Subsystem Prohibited Control 
SST - Subsystem-Status-Test 
SSTC - Subsystem Status Test Control 
UIS - User-in-Service 
UOG - User-Out-of-Service-Grant 
UOR - User-Out-of-Service-Request 
UOS - User-Out-of-Service 
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Timers 
T(stat.info) = delay between requests for subsystem status information. 
A eoond dhe) = waiting for grant for subsystem to go out of service. 
T(rtg.stat.info) = delay between requests for subsystem routing status information. 
T(ignore sst) = delay for subsystem aeeewine grant to go out of service until actually going out of 


service (provisional value = 30 seconds) 
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Figure 2/Q.714. SCCP Routing Control Procedures (SCRC) (Sheet 1 of 2) 
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Figure 2/Q.714. SCCP Routing Control Procedures (SCRC) (Sheet 2 of 2) 


ee 


TR-NPL-000246 
Issue 1, 1985 
Revision 3, June 1989 


SIGNALLING CONNECTION CONTROL PART PROCEDURES Q.714 


yooeeeeemmanng 
N 


VUE 


- N 
\N 
AMAA MAA 


Ye 


Figure 3/Q.714. SCCP Connectionless Control (SCLC) 


TR-NPL-000246 
Issue 1, 1985 
Revision 3, June 1989 


SIGNALLING CONNECTION CONTROL PART PROCEDURES Q.714 
USER 
N-STATE N-STATE N-COORD N-TRAFFIC 
IND REQ. REQ.  RESP., IND. 
IND. CONF. 


SCMG 


VOG 


MSG. FOR 
PROHIB 
SUBST Ss. Waa Na 


SCRC. “SCLC 
LBCS 


INFO 


REQUEST TFMI REQUEST 
™M ™ . 
, INFO 


SSAC 


STOP 
, START START 
SNR SSA SST SRT 
(3) Va , 
SCLC 
STOP BCST CSCC SBRC SRTC SNRC 
UOS SST 
i oie sap bewn 
REQUEST 


TM INFO SPCC 


START 
SRT 


| ssp'ssa 
SCLC 
cae 


MTP-RESUME MTP-PAUSE MTP-STATUS 
IND. IND IND. 
——’ MTP 
MTP 


Figure 4/Q.714. SCCP Management Overview (SCMG) 


‘ALLING CONNECTION CONTROL PART PROCEDURES 


IDLE 


MTP-PAUSE 
IND. 
MTP->SPPC 


MARK PC 
PROHIBITED 


UPDATE PC 
TRANSLATION 
INFORMATION 


ANY 
(MORE) KNOWN 
SUBSYSTEM AT 
PAUSED PC? 


SELECT 
SUBSYSTEM 


AT PC 
APPLICABLE 
TRAFFIC MIX 
PROCEDURES STOP SST 
(OPTIONAL) SPPC->SSTC 


MARK 
SUBSYSTEM 
PROHIBITED 


INFORM LOCAL 
CONCERNED SS'S 
OF "SP FAILURE” 


LOCAL 
BROADCAST 
OF “UOS" 
SPPC- >LBCS 


IDLE 


DOES 

BACKUP 

SUBSYSTEM 
EXXST? 


MARK SUBSYS 
TRANSLATE 
TO BACKUP 


SBR 
SPPC- >SCLC 


.714. SCCP Management; Signalling Point Prohibited Control (SPPC) 


tt 


Q.714 


5 | 


TR-NPL-000246 
Issue 1, 1985. 
Revision 3, June-1989 


SIGNALLING CONNECTION CONTROL PART PROCEDURES Q.714 


IDLE 


MARK PC 
ALLOWED & RESET 
PC CONG. LEVEL 


UPDATE PC 
TRANSLATION 
INFORMATION 


APPLICABLE 

TRAFFIC MIX 

PROCEDURES 
(OPTIONAL) 


INFORM LOCAL 
CONCERNED SS'S 
OF "SP RECOVERY~ 


. IDLE 
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Figure 7/Q.714. SCCP Management; Signalling Point Congested Control (SPCC) 
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Figure 9/Q.714. SCCP Management; Subsystem Allowed control (SSAC) 
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Figure 13/Q.714. SCCP Management; Broadcast (BCST) 


Pas a 


TR-NPL-000246 
Issue 1, 1985 
Revision 3, June 1989 


SIGNALLING CONNECTION CONTROL PART PROCEDURES Q.714 


RAR nn 


VISAS, 


REQUEST REQUEST REQUEST REQUEST 
TRAFFIC TRAFFIC TRAFFIC TRAFFIC 
MIX INFO. MIX INFO. MIX INFO. MIX INFO 

SSAC -> TFMI SPPC -> TFMI SPAC -> TFMI 


NO 


IS 
SUBSYSTEM NO 


N-TRAFFIC. REPLICATED? 


” 


IND. “NPNB 
TFMI-> USER 


NO. 
OF ADJACENT NONE 
TRAN/NODE 
ACCESSIBLE? 


NO. 
OF ADJACENT 
et NODE 
ACCESSIBLE? 


N-TRAFFIC 
IND. “A” 
TFMI-> USER 


N- TRAFFIC 
IND. “S” 
TFMI-> USER 
N- TRAFFIC 


IND. 
TFMI-> USER 


NO. 
OF ROUTING 
FLAGS NORMAL? 


ROUTING 
FLAGS NORMAL 
FOR ALL ACCESSIBLE 
INT. TRAN/NODE 


N-TRAFFIC 
IND. “APSB” 
TFMI-> USER 


N-TRAFFIC 
IND. “APNB” 
TFMI-> USER 


TRAFFIC 


IND. 
TFMI-> USER 


N-TRAFFIC 
IND. "SPSB” 
TFMI-> USER 


IND. "AP AB” 
TFMI-> USER 


IDLE 


yield 


"Wp ddddldddiisididiididi¢ddjiiiddididdisidissiéiéis,éés 


\ 
\ 
Mh hn AQAA RRR 


Figure 14/Q.714. SCCP Management; Traffic-Mix Information (TFMI) (Optional) 


TR-NPL-000246 
Issue 1, 1985 


Revision 3, June 1989 


SIGNALLING CONNECTION CONTROL PART PROCEDURES 


LW ’=>ovnnggg 


IDLE | 


SBR 
SCLC -> SBRC 


IS 
ORIGINATING NO 
SIGN 
AD 
N 
L 


ALLING PT. 
JACENT? 
is 
AMED SS 
REPLICATLD 
OCALLY? 
K ROUTING 


MAR 


EE 


MEE EEE EEE EEE Eee 


Natt ----=- TRAFIC 

\ I SBRC -> TFMI 

N | 

\ IDLE 

N N 


/ 


LQ TATA 


Q.714 


Figure 15/Q.714. SCCP Management; Subsystem Backup Routing Control (SBRC) (Optional) 
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Figure 16/Q.714. SCCP Management; Subsystem Normal Routing Control 


Wy 


en, 


SNRC) (Optional) 


_ TR-NPL-000246 
Issue 1, 1985 
Revision 3, June 1989 


SIGNALLING CONNECTION CONTROL PART PROCEDURES Q.714 


Wilf 


SSH HHH TT 


iDLE 
> ea SRT START SRT 
SPAC - > ea SBRC -> SRTC 


IN PROG SRESS 
ABOUT THIS 
SUBSYSTEM? 


SET 
“TEST IN 
PROGRESS” 


1. INITLATING NODE 


ii 2. RECEIVING NODE 


LQWWHHOH ALAA 


ts 


Figure 17/Q.714. SCCP Management; Subsystem Routing Status Test Control (SRTC}) (Optional) * 
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Figure 18/Q.714. Architecture - Dependent Traffic Mix Calculation (Optional) 
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Figure 2/T1.112.4 - SCCP Routing Control Procedures (SCRC) (Sheet 2 of 2) 
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(to Q.714) 
Examples of SCCP Routing 


1. Introduction 


This Annex contains examples of addressing used in SCCP routing of connectionless messages. They 

are intended only to describe the use of global titles and the message return function, and should not 

be taken as a specification of how SCCP routing must be used. The point code, subsystem number 
‘and global title values are symbolic only. 


2. Simple Global Title Translation 


2.1 Successful Routing 


Trans- 
lation 


Message 1 Message 2 


Figure 1 - Routing Model for Simple Successful Routing 
The initial message (message 1) from SP X has address information coded as follows: 


MTP information: 
DPC = Y 
OPC =X 
SCCP information: 
Cd Addr = GT + SSN, GT routing 


GT = 201-758 
SSN = 0000 
Cg Addr = PC + SSN, SSN routing 
PC =X 
SSN = 0101 


At STP Y, in this case GT translation results in GT 201-758 -> PC Z + SSN O111. The subsequent 
message (message 2) from STP Y to SP Z is as follows: 


MTP information: 
DPC = Z 
OPC = Y 
SCCP information: 
Cd Addr = GT + SSN, SSN routing 


GT = 201-758 
SSN = O1l1 

Cg Addr = PC + SSN, SSN routing 
PC =X 


SSN = 0101 
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2.2 Unsuccessful Routing 


It is assumed here that message return on error has been requested by the sender, SP X. If message 
return was not requested, no UDTS message would be sent. 


2.2.1 Scenario 1: Routing Problem in STP 


(x) Message 1 STP Y 


Figure 2 - Routing Failure at STP 


In this case, a routing problem occurs at the STP, resulting in a Unitdata Service message (message 
3) being returned to the sender with the following form: 


MTP information: 
‘DPC = X 
OPC = Y 
SCCP information: 
Cd Addr = SSN, SSN routing 


SSN = 0101 

Cg Addr = GT + SSN, GT routing 
GT = 201-758 
SSN = 0000 


Cause = No transl. for this address, or 
no transl. for this type, or 
network failure/congestion, or 
subsystem failure 


Note: The Called Party Address may also contain point code X, if the UDTS is generated by 
modifying the pointer values to reverse the positions of the Calling and Called Party Address 
parameters. The point code would not be used by SCCP routing, and could be dropped if global 
title translation occurs in the reverse direction. 


2.2.2 Scenario 2: Routing Problem in Terminating Node 


Message 1 


_ Message 2 | 


STP Y 


Message 4 


Figure 3 - Routing Problem in Terminating Node 
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In this case, a routing failure occurs in the terminating node, and if message return has been 
requested, the following UDTS message (message 4) is returned to the sender: 


MTP information: 
DPC =X 
OPC = Z 
SCCP information: 
Cd Addr = SSN, SSN routing 


SSN = 0101 

Cg Addr = GT + SSN, SSN routing 
GT = 201-758 
SSN = 0111 


Cause = Subsystem failure, or 
unequipped user 


Note: If the pointer modifying method is used, the Called Party Address would contain the point 
code X. 


| 3. Routing to Distribute Translation Load 


This section provides an example of routing where a different point does global title translation for 
messages with different “classes” of global titles to be translated. This allows the total global title 
translation load to be distributed over a number of STPs. One example of how global titles may be 
differentiated into classes would be to use the translation type. 


Figure 4 - Routing Model 


The first message (message 5) from SP X has the address form: 
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MTP information: 
DPC = Y 
OPC =X 
SCCP information: 


Cd Addr=GT+SSN, GT routing 
GT = 201-758, Type = A 


SSN = 

Cg Addr=PC+SSN, SSN routing 
PC =X 
SSN = 0101 


Messages with this type of address are directed toward STP Y for global title translation. 


A second message (message 6) from SP X carries a global title with different translation type, as 


follows: 
MTP information: 
DPC = Q 
OPC =X 
SCCP information: 


Cd Addr=GT+SSN, GT routing 
GT = 201-758, Type = B 


SSN = 

Cg Addr=PC+SSN, SSN routing 
PC =X 
SSN = 0101 


In this case, the message is passed through STP Y via MTP routing. The translation of global titles 
follows the pattern for successful simple routing. | 
4. Routing with Multiple Translations 


This section provides models for routing where multiple points do global title translation on a single 
message, from a user’s perspective, during that message’s transit. 


4.1 Successful Routing 


Trans- 
lation 


Msgl J stpy 


Msg rf 


Trans- 
lation 


STP Q 


Msg 8 
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Figure 5 - Routing for Multiple Translations 


Message 1 carries information as described in section 2.1 of this annex. In this case, GT translation 
at STP Y results in GT 201-758 -> PC Q and GTT 212, and no SSN is determined. The subsequent 
message (message 7) from STP Y takes this form: 
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MTP information: 
DPC = Q 
OPC = Y 


SCCP information: 
Cd Addr = GT + SSN, GT routing 
GT = 212 
SSN = 0000 
Cg Addr = PC + SSN, SSN routing 
PC =X 
SSN = 0101 


When this message is received at point Q, a second translation takes place with a subsystem number 
and point code being identified, and message 8 is forwarded to SP Z with the form: 


MTP information: 
DPC = Z 
OPC =Q 
SCCP information: 
Cd Addr = GT + SSN, SSN routing 
GT = 212 
SSN = 0111 
Cg Addr = PC + SSN, SSN routing 
PC = X 
SSN = 0101 
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4.2 Failure Case 


Trans- Trans- 
lation lation 


Msg 1 Msg 7 


STP Y STP Q 


Msg 9 | allure 


Figure 6 - Routing Problem at Second Translation Point 


In this case, a routing failure has taken place at the second translation point. This failure results in 
the sending of a Unitdata Service message (message 9) back to the Calling Party as follows: 


MTP information: 
DPC = X 
OPC =Q 
SCCP information: 
| Cd Addr = SSN, SSN routing 


SSN = 0101 

Cg Addr = GT + SSN, GT routing 
GT = 212 
SSN = 0000 


Cause = No translation for this address, or 
no translation for this type address, or 
network failure or congestion, or 
subsystem failure or congestion. 


In this case, the calling party cannot determine the original called party address value from the 
UDTS message, due to the intervening translation. 
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